home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.19980424-19980901
/
000088_news@newsmaster….columbia.edu _Sun May 17 18:46:02 1998.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
3KB
Return-Path: <news@newsmaster.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id SAA10625
for <kermit.misc@watsun.cc.columbia.edu>; Sun, 17 May 1998 18:46:01 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id SAA21694
for kermit.misc@watsun; Sun, 17 May 1998 18:46:01 -0400 (EDT)
From: heiby_u@falkor.chi.il.us (Ron Heiby)
Subject: CRC-CCITT in C-Kermit?
Date: Sun, 17 May 1998 22:35:52 GMT
Organization: Strategis Consulting Inc.
Message-ID: <355f6176.22879615@149.174.211.108>
X-Newsreader: Forte Agent 1.5/32.451
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Newsgroups: comp.protocols.kermit.misc
Path: news.columbia.edu!panix!howland.erols.net!ais.net!WCG!arl-news-svc-3.compuserve.com!news-master.compuserve.com!nntp-ntawwabp.compuserve.com
Lines: 48
Xref: news.columbia.edu comp.protocols.kermit.misc:8741
Hi! I'm trying to come up with definition and example implementation of
CRC-CCITT for a standards effort I'm involved with.
I have run across several implementations that claim to implement CRC-CCITT.
One of these provided both table-driven and non-table implementations (that
resulted in the same values for the tests I ran). Then, there's another
table-driven implementation that comes up with a different value, but the
same value as is obtained from the MKS Toolkit's "sum -i" command. These two
table-driven implementations each use a table of 256 16-bit elements that
have different element values.
Then, we have the code used by C-Kermit. This code appears to use two tables
of 16 16-bit elements each, quite a few less than the other two table-driven
implementations, but with more computation, though less computation than the
non-table implementation I found. But, this code seems to come up with yet a
third value for my test cases.
Then, we have information that was quoted to me from an X.25 spec, that
indicates that the CRC must be pre-loaded with 0xffff and other
complexities, but which never really comes out and gives a step-by-step
procedure that someone who hasn't seen "New Math" in many years could hope
to follow.
I'd really appreciate it if someone could give me a hand with this. The
implementations I have from the same person with both table and non-table
versions giving the same result are very attractive, as the receiving side
can clock in the transmitted (LSB, MSB) CRC through the calculation and get
0x0000 if the frame arrived intact. This seems simpler than cranking octets
through two behind, in case these last two are the CRC, then comparing the
result of the calculation with those last two octets. But, I want to make
sure that what I use will actually work.
Here's the non-table code that I'd like to use if I can.
unsigned short crcccitt(unsigned short crc, unsigned char c)
{
unsigned short newcrc;
newcrc = (crc & 0xff) ^ char;
newcrc = newcrc ^ (newcrc << 4);
newcrc = (newcrc << 8) ^ (newcrc << 3) ^ (newcrc >> 4) ^ (crc >> 8);
return newcrc;
}
Thanks much!